Skip to content

Add reporting feature to GitHub webhook-based taskspawner#966

Open
kelos-bot[bot] wants to merge 3 commits intomainfrom
kelos-task-958
Open

Add reporting feature to GitHub webhook-based taskspawner#966
kelos-bot[bot] wants to merge 3 commits intomainfrom
kelos-task-958

Conversation

@kelos-bot
Copy link
Copy Markdown

@kelos-bot kelos-bot Bot commented Apr 11, 2026

What type of PR is this?

/kind feature

What this PR does / why we need it:

Adds GitHub status reporting support for webhook-based TaskSpawners, achieving feature parity with the polling-based GitHubIssues and GitHubPullRequests sources.

When reporting.enabled: true is set on a GitHubWebhook source, the webhook server will:

  1. Stamp reporting annotations (kelos.dev/github-reporting, kelos.dev/source-kind, kelos.dev/source-number) on newly created Tasks
  2. Watch Task status transitions and post/update comments on the originating GitHub issue or PR

The implementation follows the existing annotation-driven reporting pattern — the reporting infrastructure is source-agnostic and only requires the correct annotations to be present on the Task.

Which issue(s) this PR is related to:

Fixes #958

Special notes for your reviewer:

  • The webhook server now accepts optional --github-owner, --github-repo, --github-token-file, and --github-api-base-url flags to enable the reporting controller. If owner/repo are not provided, the reporting controller is not started.
  • The webhookSourceKind() helper correctly maps webhook event types to the existing "issue" / "pull-request" annotation values. For issue_comment events on PRs, it checks the PullRequestAPIURL field.
  • Reporting annotations are only stamped when the event has a non-zero Number (push events, for example, are skipped).

Does this PR introduce a user-facing change?

Add reporting support to GitHubWebhook-based TaskSpawners. Setting `reporting.enabled: true` on a webhook source posts status comments back to the originating issue or PR, matching the behavior already available for polling-based sources.

Summary by cubic

Adds GitHub status reporting to webhook-based TaskSpawners so tasks spawned from webhook events post and update status comments on the originating issue or PR, matching polling sources.

  • New Features

    • Enable via spec.when.githubWebhook.reporting.enabled: true.
    • Stamps kelos.dev/github-reporting, kelos.dev/source-kind, and kelos.dev/source-number on tasks.
    • Adds a reporting controller to cmd/kelos-webhook-server, gated by --github-owner, --github-repo, --github-token-file, and --github-api-base-url.
    • Maps webhook events to issue or pull-request (e.g., issue_comment on PRs maps to pull-request); skips events without a number (e.g., push).
    • Reporting reconciler now triggers on Task phase changes only; spawner reportingEnabled() is scoped to polling sources (webhook reporting is handled by the webhook server).
  • Migration

    • Upgrade CRDs.
    • For webhook reporting: set reporting.enabled: true on GitHubWebhook sources and run the webhook server with the GitHub flags; provide a token via --github-token-file or GITHUB_TOKEN.

Written for commit 7a9816b. Summary will update on new commits.

This enables status reporting back to GitHub issues/PRs for tasks
spawned via webhook events, achieving feature parity with the
polling-based GitHub issue and pull request sources.

Changes:
- Add Reporting field to GitHubWebhook CRD struct
- Stamp reporting annotations on webhook-created tasks when enabled
- Add reporting reconciler to webhook server binary
- Update reportingEnabled() to check webhook sources
- Regenerate CRD manifests and deepcopy

Co-Authored-By: Claude Opus 4.6 <[email protected]>
@github-actions github-actions Bot added needs-triage needs-kind Indicates an issue or PR lacks a kind/* label needs-priority needs-actor release-note kind/feature Categorizes issue or PR as related to a new feature and removed needs-kind Indicates an issue or PR lacks a kind/* label labels Apr 11, 2026
Copy link
Copy Markdown

@cubic-dev-ai cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 issue found across 10 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="cmd/kelos-spawner/main.go">

<violation number="1" location="cmd/kelos-spawner/main.go:484">
P1: Webhook reporting is still effectively disabled: this new `GitHubWebhook` check is bypassed by `sourceAnnotations` returning early for webhook sources, so webhook-created tasks won't receive reporting annotations.</violation>
</file>

Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.

Comment thread cmd/kelos-spawner/main.go Outdated
if ts.Spec.When.GitHubPullRequests != nil && ts.Spec.When.GitHubPullRequests.Reporting != nil {
return ts.Spec.When.GitHubPullRequests.Reporting.Enabled
}
if ts.Spec.When.GitHubWebhook != nil && ts.Spec.When.GitHubWebhook.Reporting != nil {
Copy link
Copy Markdown

@cubic-dev-ai cubic-dev-ai Bot Apr 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1: Webhook reporting is still effectively disabled: this new GitHubWebhook check is bypassed by sourceAnnotations returning early for webhook sources, so webhook-created tasks won't receive reporting annotations.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At cmd/kelos-spawner/main.go, line 484:

<comment>Webhook reporting is still effectively disabled: this new `GitHubWebhook` check is bypassed by `sourceAnnotations` returning early for webhook sources, so webhook-created tasks won't receive reporting annotations.</comment>

<file context>
@@ -481,6 +481,9 @@ func reportingEnabled(ts *kelosv1alpha1.TaskSpawner) bool {
 	if ts.Spec.When.GitHubPullRequests != nil && ts.Spec.When.GitHubPullRequests.Reporting != nil {
 		return ts.Spec.When.GitHubPullRequests.Reporting.Enabled
 	}
+	if ts.Spec.When.GitHubWebhook != nil && ts.Spec.When.GitHubWebhook.Reporting != nil {
+		return ts.Spec.When.GitHubWebhook.Reporting.Enabled
+	}
</file context>
Fix with Cubic

…gedPredicate

The reportingAnnotationPredicate watches Task status phase changes directly.
GenerationChangedPredicate is removed to avoid reconcile churn from annotation
updates that bump metadata.generation.

Co-Authored-By: Claude Opus 4.6 <[email protected]>
@gjkim42
Copy link
Copy Markdown
Collaborator

gjkim42 commented Apr 11, 2026

/kelos pick-up

The webhook check in reportingEnabled() was unreachable in the spawner
context because sourceAnnotations() returns early for webhook sources.
Webhook reporting annotations are stamped directly by the webhook
handler, not the spawner. Remove the dead code and its tests.

Co-Authored-By: Claude Opus 4.6 <[email protected]>
@gjkim42
Copy link
Copy Markdown
Collaborator

gjkim42 commented Apr 12, 2026

/kelos review

1 similar comment
@gjkim42
Copy link
Copy Markdown
Collaborator

gjkim42 commented Apr 12, 2026

/kelos review

Copy link
Copy Markdown
Author

@kelos-bot kelos-bot Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 Kelos Reviewer Agent @gjkim42

Review Summary

Verdict: APPROVE (submitted as comment — cannot self-approve)
Scope: Adds GitHub status reporting to webhook-based TaskSpawners via annotation stamping and a new reporting reconciler in the webhook server

Findings

Tests (non-blocking)

  • cmd/kelos-webhook-server/reporting.go — No test file exists for this new file. The reconciler, reportingAnnotationPredicate, and readGitHubToken are untested. The handler-side tests (internal/webhook/handler_test.go) are thorough and cover annotation stamping, disabled reporting, PR events, and source kind mapping — but the webhook server's reporting controller should also be tested, at minimum for readGitHubToken edge cases (file not found, empty file, env var fallback) and the predicate filtering logic.

Code Quality (non-blocking)

  • cmd/kelos-webhook-server/reporting.go:101 vs cmd/kelos-spawner/main.go:641readGitHubToken is duplicated with subtle behavioral differences: (1) the webhook version correctly falls back to GITHUB_TOKEN when the token file is empty, while the spawner version returns an empty string; (2) the webhook version omits the file path from the error format string ("reading token file: %w" vs "reading token file %s: %w"). Consider extracting to a shared function in internal/reporting/ to avoid this divergence.

Correctness (nit)

  • internal/webhook/handler.go:503webhookSourceKind includes "pull_request_target" in the switch. This is a GitHub Actions trigger concept, not a standard GitHub webhook event type (the webhook API has pull_request, pull_request_review, pull_request_review_comment, and pull_request_review_thread). It's harmless since no real webhook would deliver this event type, but it's slightly misleading.

Verification

  • make verify — passes
  • make test — all tests in changed packages pass (internal/webhook OK, cmd/kelos-spawner OK)
  • Generated files (deepcopy, CRD YAMLs) are included and up to date
  • PR description follows the template, includes a meaningful release note for the new user-facing feature

Suggestions

  • Add unit tests for readGitHubToken and reportingAnnotationPredicate in a new cmd/kelos-webhook-server/reporting_test.go
  • Extract the shared readGitHubToken into internal/reporting/ to avoid the subtle behavioral divergence between copies
  • Consider adding the annotation check to reportingAnnotationPredicate.Create to avoid unnecessary reconciles for tasks without reporting annotations (the current approach works correctly but reconciles and discards all non-reporting task creates)

@knechtionscoding
Copy link
Copy Markdown
Contributor

@gjkim42 I was thinking of picking up the #846 and wanted to wait till after this lands so we get reporting on webhooks spawners as well. Any blockers to this being merged?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

add reporting feature to github webhook based taskspawner.

2 participants